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1 Introduction 

Haskell, a wide spectrum, functional programming 
language, provides means to define and use an ex¬ 
tremely rich variety of data including free, polymor¬ 
phic datatypes, type classes, and data with addi¬ 
tional computational structure abstracted by mon¬ 
ads. Somewhat less attention has been given to sup¬ 
porting abstract data types, which we shall call co¬ 
data types. Monomorphic, parameterless versions of 
codata types can be defined by modules, but Haskell’s 
module system is not comparably powerful with the 
class system. 

Through a relatively innocuous and well under¬ 
stood extension, namely rank 2 polymorphic types, 
Haskell can provide first-class codata types. This sug¬ 
gestion has precedents. Laufer and Odersky [L094] 
have advocated first-class abstract data types as an 
extension of algebraic data types and have suggested 
existential type quantification as a means of hiding 
representations. Their suggestions were first imple¬ 
mented in the hbc compiler for Haskell and in an 
undistributed version of Caml-Light. Subsequently, 
rank 2 polymorphism has been implemented as a 
Haskell extension in Hugs versions 1.3 and Hugs98 
and in the ghc compiler. Simon Peyton Jones has 
suggested that with the ability to hide a representa¬ 
tion type, Haskell’s modules permit the declaration of 
abstract objects (without an inheritance mechanism) 
[Jon99], 

The second topic of the paper is comonads in 
Haskell. Monads are by now well known and have 
been found to be extremely useful in programming. 
Monads serve several purposes: 

• they integrate semantic effects into an otherwise 
purely functional framework [Mog91]; 

• they provide easily interchangeable semantic in¬ 
terpretations of a common program framework 
[Wad92]; 

• they suggest type system extensions that can 
enforce static encapsulation of state [LP95] and 
other effects [Kie98]. 

1 The research reported in this paper was supported by 
the USAF Materiel Command. 


Monads account for computational effects of exe¬ 
cuting a program segment. Many computational ef¬ 
fects can be restricted to a segment of a program in 
which the effect is visible. To encapsulate an effect, 
there must be a means to initialize the effect mech¬ 
anism and to recover a pure value from a program 
segment that relies upon the effect. The use of a lo¬ 
cal state variable in a computation is an example of 
an encapsulatable effect mechanism. 

Every monad provides a polymorphic combinator 
that injects a value into an effect-dependent computa¬ 
tion (the unit of the monad, called return in Haskell). 
The bind combinator extends effect-dependent func¬ 
tions to functions that take effect-producing compu¬ 
tations as arguments, so they may be composed. 

However, monads do not account as naturally for 
effects that derive from the context in which a pro¬ 
gram segment is executed. A program can always 
project a value from a computation passed to it from 
its context. Otherwise, the imported computation 
would have no interaction with the program. How¬ 
ever, not every value can be injected into a compu¬ 
tation meaningful in the context. Some types de¬ 
fined within the program may be unknown in the con¬ 
text. This is complementary to the circumstance of 
a monadic effect, where a computation in the monad 
can be constructed with the return combinator at 
every type, but the ability to extract a value from a 
monadic computation is not universal. 

Take monadic input/output, for instance. Con¬ 
ceptually, the 10 monad encapsulates effects in which 
the Haskell program’s evaluation may “change the 
world”. However, the 10 operations of a program do 
not so much change the world as they allow a pro¬ 
gram to respond to a changing world. The 10 system 
is provided by the context in which a Haskell program 
is executed; it is not defined by Haskell’s semantics. 
We note that an 10 subsystem is not initialized by a 
Haskell program. The Haskell implementation does 
not determine the representation of its objects, and 
its effects cannot be restricted to just those effects 
manifested by executing a Haskell program. 

To further support this point of view, note that 
when a program reads or writes to a hie other than the 
standard input or output, a hie handle is required as 
an argument of the functions; the basic 10 operations 
to a hie are typed as: 

hGetChar :: Handle -> 10 Char 

hPutChar :: Handle -> Char -> 10 () 

If the type constructor 10 is interpreted to designate 
a computation manifesting a side effect of an 10 sys¬ 
tem, these types are unintuitive. It is surprising that 
the Handle type, which is associated only with the 
hie system and whose semantics is said to be “imple¬ 
mentation dependent”, does not appear under the 10 
type constructor. 








A more intuitive typing for these operators might 
be: 

hGetChar’ :: 10 Handle -> Char 

hPutChar’ :: 10 Handle -> 10 Char -> () 

With this typing, it is more natural to associate the 
effect of the 10 subsystem with the environment in 
which a program is run, a concept that seems better 
aligned with reality than is the view that 10 is an 
effect determined by Haskell semantics. 

The types suggested here for hGetChar ’ and 
hPutChar ’ are typical of functions typed in a 
comonad, the mathematical structure dual to a 
monad. This paper suggests that a useful interpre¬ 
tation of comonads in programming is that they ac¬ 
count for effects originating in the context of a pro¬ 
gram fragment, effects to which the program frag¬ 
ment may react and which it may further propagate. 
We shall see several examples in a later section. 

2 Codata types and modules 

Codata is an appropriate name for objects that have 
historically been called abstract data types. These 
objects differ from data in several, fundamental re¬ 
spects: 

• The structure of a data object is exposed, while 
the structure of a codata object is hidden. 

• Unlike a data object, a codata object does not 
have the attributes ordinarily associated with a 
“value”. The show function is not defined on a 
codata object; codata cannot belong to the Eq 
class; there are no derived methods on a codata 

• A data object has open access, as its structure 
is visible. A codata object has only the ac¬ 
cess methods specified by its declaration. These 
methods comprise a set of typed functions, some 
of which yield data values when invoked, and 
some of which may yield a new codata object. 

• Data objects are usually Unitary (lazily evalu¬ 
ated recursive data structures are an exception 
to this rule) while codata objects are usually in- 
finitary (finite records are an exception to this 

2.1 Streams 

There are many familiar examples of codata objects 
in programming. Infinite streams furnish a particu¬ 
larly simple example. A stream is a sequence whose 
elements are only accessible in order. A stream co¬ 
data type is characterized by two access methods: 

shd :: Stream a —>■ a 
stl :: Stream a —>■ 


The access methods of any codata object are total 
functions. Since the stl function can be iteratively 
applied without bound, a stream is seen to be an 
infinitary object. 

Haskell programmers often make use of streams, 
encoded as lazy lists. The functions shd and stl are 
represented by functions hd :: List A —>■ A and tl :: 
List A —>■ List A which can be defined in terms of 
pattern matches on the structure of a list argument. 
However, hd and tl are partial functions which may 
raise a pattern match exception if applied to an empty 
list. A lazy list representation simulates a stream, but 
lazy lists are not isomorphic to streams. 

Furthermore, the stream codata type does not im¬ 
ply that an evaluated stream segment is automati¬ 
cally cached, as does the lazy evaluation of a segment 
of a list. While the caching of values provided by 
lazy evaluation is often important 2 , its benefit is not 
without cost in time to access a value. If a function 
over stream data can be computed synchronously and 
scheduled deterministically, then uncached elabora¬ 
tion of a stream could be more economical. 

Other examples of codata in programming are the 
“objects” of languages such as Java, Smalltalk, Eiffel 
and C-|—|-. Of course, these object-oriented languages 
provide stateful objects rather than functional ob¬ 
jects as their default. They also support inheritance 
among object classes, which is a notion orthogonal 
to that of codata. However, the notion of objects re¬ 
stricted to abstract data types has a long history in 
programming, and was found in early versions of the 
functional language, ML. 

2.2 Modules declare codata types 

Module declarations are the mechanism provided in 
Haskell to hide representation while exporting access 
methods. Modules should provide the means to de¬ 
fine new codata types, but unfortunately, standard 
Haskell modules are not equipped with a sufficiently 
expressive type structure. Suppose, for instance, that 
we wish to define a Haskell module to export the op¬ 
erators of a polymorphic stream type. We would like 
to write a module declaration such as: 

module Stream 

(Stream, 
shd, 
stl, 

mkStream 

) 

where 

data Stream a = S b (b -> a) (b -> b) 

over streams P [LLC99], failure to cache evaluated stream seg¬ 
ments can cause the time complexity of an algorithm to grow 
from linear to exponential, if a stream is duplicated in the 
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shd :: Stream a -> a 
shd (S x f g) = f x 

stl :: Stream a -> Stream a 
stl (S x f g) = S (g x) f g 

mkStream :: 

b -> (b -> a) -> (b -> b) -> Stream a 
mkStream xfg=Sxfg 

in which the type variable b occurring in the decla¬ 
ration of the data type Stream a designates a hid¬ 
den representation type (this is the carrier type of 
a stream coalgebra). However, this type variable is 
unbound in the text given above and the data type 
declaration will not be accepted. The type variable 
b could be bound along with the type parameter a 
of the Stream data type declaration, but this would 
reveal the representation type, as the exported type 
would be Stream a b. If this binding was adopted, 
the representation type would be visible in the type 
of each instance of a stream. 

A solution that preserves the stream abstraction 
is furnished by rank 2 polymorphism (universal quan¬ 
tification over types, nested within type expressions) 
which has been implemented as an extension to stan¬ 
dard Haskell in the ghc and hbc compilers and the 
Hugs interpreter. The syntax we use here is valid 
in Hugs version 1.3 and Hugs98, when run in Hugs- 
extensions mode. The keyword forall can be used 
to bind a type variable within a declared type expres¬ 
sion. Using this facility, the data type declaration 
within the module above can be written as 

data Stream a = 

forall b. S b (b -> a) (b -> b) 

In this declaration, the type variable b is in scope only 
in the domain type of the signature of the unexported 
data constructor, S. 

The declaration above uses universal quantifica¬ 
tion over a type variable that occurs in the domain 
type of a constructor to realize an existential type 
quantification. The logical equivalence on which this 
trick relies is (Mb. P =>• Q) = ((3b. P) =>• Q), when 
b has no free occurrence in Q. The apparently su¬ 
perfluous data constructor, S, in the type declaration 
of Stream a effectively represents the leftmost impli¬ 
cation in the formula above, when P stands for the 
type (b, (b -> a), (b -> b)) and Q stands for the 
type Stream a. In each instance of an expression of 
the declared datatype, the bound type variable may 
be independently instantiated to a specific type. 

When the declaration above is substituted for the 
datatype declaration in the module Stream, the mod¬ 
ule declaration is accepted by the Hugs98 interpreter 
and exports the type constructor Stream along with 
the signatures of the three operators shd, stl and 


mkStream. The data constructor S and the repre¬ 
sentations of the exported functions remain hidden 
to users of the module. To create an instance of a 
stream, a program invokes mkStream applied to three 
appropriately typed arguments. For example, 
let fibs = mkStream (1,1) 

(\(j,k) -> (k,j+k)) 

specifies the Fibonacci sequence as a stream of inte¬ 
gers. 

A potential drawback of including the “forall” 
quantifier in Haskell data types is that a pattern 
match on a data value constructed in a type whose 
constructors take arguments of a quantified type 
might then escape its intended scope (and the scope 
of the module). A potential escape of scope can easily 
be detected if type quantification is restricted to dec¬ 
larations of data constructors that are not exported 
from a module declaration. Encapsulation of a quan¬ 
tified type can be enforced by type checking if the use 
of explicit type quantification is so restricted. 

2.3 A theory of codata 

In this section, we provide a brief, intuitive and en¬ 
tirely descriptive summary of the rich theory that un¬ 
derlies codata objects. 

Mathematically, codata objects are structure coal¬ 
gebras. Recall that a coalgebra consists of a type, t, 
together with a tuple of one or more total functions, 
each of which has t as its domain type. The type, t, 
is called the carrier of a coalgebra and the functions 
are its access methods. 

The “structure” of a coalgebra is specified by the 
collection of codomain types in the signature of its 
access methods. There may, of course, be many coal¬ 
gebras with the same signature. These constitute a 
class, or co-variety, characterized by their common 
signature. 

If the access methods of a coalgebra are speci¬ 
fied only up to their signatures, as is the case for the 
Stream codata type discussed in the preceding sec¬ 
tion, then the coalgebra is said to be cofree. A cofree 
coalgebra is generic in the sense that its theory is also 
satisfied by every other coalgebra in its class. A coal¬ 
gebra specification that was not cofree would include 
additional equations relating its access methods. 

An abstract codata declaration specifies an entire 
class of coalgebras, each with the structure given in 
the specification module. To form an instance of the 
coalgebra class it is necessary to give a representa¬ 
tion type and implementations for each of the ac¬ 
cess methods. Notice that the mkStream method for 
the Stream codata type requires three parameters: a 
value in the representation type that is used to ini¬ 
tialize the stream, and two functions that implement 







the shd and stl access methods. The representation 
type can be inferred from the first argument passed 
to mkStream. Thus the parameters of mkStream fur¬ 
nish the data required to form a concrete instance of 
the Stream coalgebra class. 

When a coalgebra is polymorphic in its represen¬ 
tation type and its access methods are prescribed only 
up to their types, it is said to be final. A final Stream 
coalgebra is what remains visible when the represen¬ 
tation of a stream is hidden. The importance of final 
codata types is that they allow programs to be writ¬ 
ten generically, to operate on any object of the codata 
type, whereas a program that relies upon a specific 
representation, such as the lazy-list representation of 
streams in Haskell, must be modified if it is to operate 
on other representations of the same class of codata. 

A recent series of papers by Bart Jacobs offers 
a formal theory of objects modeled as coalgebras 
[Jac95, Jac96a, Jac96b]. 

3 Comonads 

A comonad is a dual structure to a monad. Formally, 
a comonad consists of: 

• a type constructor, W, taking a single argument 

• a polymorphic function co-eval : Wa —>■ a, 

• a polymorphic function 

co-ext : (Wa ->■ b) ->■ Wa ->■ Wb, 

• three laws: 

co-ext co-eval = idw ( right-id) 

co-eval. co-ext f = f (left-id) 

co-ext f . co-extg = co-ext(f . co-extg) (assoc) 

Monads and comonads are intimately related in cat¬ 
egory theory, but we shall not go into that aspect in 
this paper. 

Monads have been added to Haskell almost exclu¬ 
sively through its libraries. The only syntactic con¬ 
cession to monads in Haskell that could not be re¬ 
alized through definitions of classes and operators is 
the do syntax. Comonads can similarly be added by 
declaring a class 

class Comonad ¥ where 

(=») : : w a -> (w a -> b) -> w b 

(.») : : w a -> b -> w b 

The infix operator =>> is the function co-ext with 
its argument positions reversed to correspond to the 
“bind” operator of a monad in Haskell. As is the 
case with the Monad class, it is the programmer’s re¬ 
sponsibility to assure that the functions supplied in 
forming an instance of the Comonad class satisfy the 


three laws required of a comonad. If these laws are 
not satisfied, then the behavior of the class instance 
may not be as expected. 

The combinator (•>>) serves to propagate de¬ 
mand to its first argument, which otherwise might 
not be evaluated by the lazy evaluation rule. It sat¬ 
isfies the equivalence: 

ei . >> e 2 = seq ei e 2 

3.1 Monads, comonads and functional purity 

In Haskell, an expression typed in an effects monad, 
such as St or 10, signals the possibility of a side effect 
occurring when a value of the expression is demanded. 
Because of the possibility of effects, demands for val¬ 
ues of monadically typed expressions are scheduled 
statically through the use of a special combinator. To 
apply a function typed as a -> m b to an argument 
typed as m a, where m is a type constructor belong¬ 
ing to the Monad class, one must use the monad bind 
operator (or the do syntax, as shorthand). The bind 
operator forces sequential evaluation, to the extent 
required by the semantics of a particular monad in¬ 
stance. In the 10 monad, whose effects may be the 
most far-reaching, bind effectively implements call- 
by-value function application. 

3.1.1 Monads encapsulate effects 

It is impossible to write a side-effecting Haskell ex¬ 
pression that isn’t typed in a monad without us¬ 
ing an explicitly unsafe coercion operator, such as 
unsafePerformlO, to circumvent the normal typing 
rules. We shall call programs that use such coercions 
“unsafe” Haskell programs; otherwise in our discus¬ 
sion we assume safe Haskell programs. 

Note that a function typed as a -> m b (where 
m may be a monadic type constructor but a is not 
a monadic type) is pure; applying such a function 
to an argument of type a can have no side effect. 
The codomain type, m b, is a poset of computations 
in the monad named by m, but any such computa¬ 
tion remains suspended until its evaluation is forced 
by a demand for a type b value or for the state of 
the monad. Applications of the bind operator force 
such evaluations; these are the only sites within a 
safe Haskell program at which demands for poten¬ 
tially side-effecting computations occur. 

An impure function is identified with a type 
m a -> b. That is, its domain type is monadic. The 
typing assertion unsaf ePerf ormlO : : 10 a -> a 
warns of this function’s intrinsic impurity. There are 
no impure functions in the Haskell standard prelude, 
apart from bind, an operator of the class Monad. 

An impure function must either be introduced in 
a library extension as an explicitly unsafe operator, 






or programmed using one of the existing unsafe coer¬ 
cions (an unsafe programming practice) or it must be 
programmed using bind. For example, the monadic 
map of a function f : : a -> b is 

mapf :: Monad m => (a -> b) -> m a -> m b 

mapf f mx = mx >>= \x -> return (f x) 

The function mapf f is potentially impure, even if f 
is a pure function, because to evaluate an application 
of mapf f forces evaluation of its monadically typed 
argument. 

Haskell’s type system assures that an impure func¬ 
tion gotten by safe programming, that is, only with 
bind, has its codomain typed in the same monad as its 
argument 3 . This ensures that any application of an 
impure function (which may produce a side effect) is 
typed in a monad that encapsulates the effect. Thus, 
no expression that is not typed in a monad can evi¬ 
dence a side-effect in a safe Haskell program. 

Typically, 10 operations of a Haskell program are 
performed in the main module, which has the type 
() -> I0(). This type indicates that it is evaluated 
only for its effects, which are manifested through the 
10 system. One can think of its linkage to the under¬ 
lying runtime system as an implicit bind operation in 
the 10 monad. 

3.1.2 Comonads can also encapsulate effects 

Projection of a value from an expression typed in the 
comonad is not a side-effecting computation. The 
combinator coeval provides such a projection at ev¬ 
ery type. A potentially side-effecting computation 
constructs a value typed in the comonad. When 
context-dependent effects are expressed in terms of 
a comonad, a function typed as ¥ a -> b, where ¥ is 
a type constructor that belongs to the class Comonad, 
is pure—application of the function cannot manifest a 
side effect. Of course, in a lazy language, evaluating 
an application may propagate demand for the con¬ 
struction of a value typed as ¥ a, which can produce 
an effect. 

The key to making comonadic effects safe, then, 
is to restrict, via the type system, computations of 
values of type ¥ a. Since comonads are used to en¬ 
capsulate effects defined in the context of a program, 
an effects-safe program can allow comonadic effects 
to be introduced only by expressions formed by ap¬ 
plications of the ’cobind’ operator, (=>>). However, 
since there is no Haskell constant of a type ¥ a, there 
isn’t any initial argument for an application of (=>>). 

To remedy this situation yet assure that effects- 
capable computations are typed in a comonad, 
we suggest a top-level program of the form 


3 Strictly speaking, the codomain could be typed in a com 



* =>> main(), where ’*’ represents an unspecified 
constant of type ¥ (). This allows main to be typed 
as ¥ () -> (), and hence to consist of a series of 
comonadic functions composed with (=>>). 

With these restrictions, no function with a type 
a -> ¥ b can be applied, where a is not a comonadic 
type. Thus every function application is safe for 
comonadic effects. 

The suggestion of a top-level program structured 
to admit sequential evaluation of expressions that 
may produce effects is not original. In his seminal 
1978 Turing award paper [Bac78], John Backus in¬ 
troduced the functional language FL, but suggested 
in a later chapter of the paper that programs that in¬ 
teract with their environments would need imperative 
code at the top level. He suggested a language that 
he called AST (Applicative State Transitions) which 
is imperative at the top level, but relies upon FL to 
declare the functions it uses. 

3.2 Some useful comonads 

Comonads have not been widely recognized in connec¬ 
tion with programming, because attention has been 
focused primarily on semantic effects of a program 
itself. However, the effects arising from a program’s 
context can be equally important. Contextual effects 
are captured by comonads. In some cases we shall 
give explicitly a datatype construction that could rep¬ 
resent the effect functionally. In others, such as IO, it 
does not seem useful to encode the effect mechanism 
in a functional representation that we do not consider 
to be an accurate operational model. 

3.2.1 State in context 

For our first comonad, let’s consider a monad of state, 
where the state exists in a context. 

Co-St.a = ((s^a), s) 

co-extf = (A (g, s).(As'. f (g, s')), s) 

The functor map is 

mapCo-Stf = A (g,x).(f.g, x) 

This comonad affords a different view of state 
than does the monad of state. The co-eval opera¬ 
tor projects an observable value from the state com¬ 
ponent. Given a function / :: Co-St s a ^ b, an 
application of the co-extension co-ext / yields a com¬ 
putation in the comonad, equipped with a new func¬ 
tion to project an observable value from the state. 
Whether and when the state component itself is mu¬ 
tated depends upon the context of the program that 
embodies this comonad, not upon the action of the 
program. 






3.2.2 A comonad of Streams 

As a second example, let’s consider an abstract view 
of streams, one in which the representation type is 
opaque. 


Stream A = (representation hidden } 

co-ext f = As. mkStream s f stl 
The co-extension satisfies a pair of equations: 

shd o (co-extf) = f 

stl o (co-extf) = (co-extf) o stl 

These equations express a universal property; a ho¬ 
momorphism that holds for every Stream object. 

The Stream comonad map is an instance of the co¬ 
extension, namely map Stream / = co-ext (f o shd). 
Accordingly, mapStream f has the properties: 

shd o mapStream f = f o shd 

stl o mapStream f = mapStream f o stl 

For example, if we reveal the representation used 
in the Haskell module Stream of Section 2, it is easily 
seen that 


co-exth (Ssfg) = Ss (Xs', h (S s'f g)) g 

satisfies the equations required of the co-extension. 
In practice, however, one would not wish to reveal 
the representation of a stream object 4 . Instead, the 
Stream comonad should be defined in the module 
Stream with the functions co-eval and co-ext as ex¬ 
ported functions. 


3.2.3 Using streams in programs 

Reactive programs produce output events in response 
to input events. A reactive program is synchronous 
if each output event is produced in response to an 
individual input event and is deposited into the pro¬ 
gram’s dynamic execution context before the context 
changes state or produces another input event. Thus 
a synchronous reactive program can be characterized 
by an event-transforming function, / :: input events 
output event. The reactive program is mapStream / :: 
Stream(input event ) —>■ Stream(output event). 

In applications such as programming a simulator 
for a microprocessor architecture [LLC99] it is neces¬ 
sary to express a stream delayed by some fixed num¬ 
ber of elements. When a stream, s, is represented by 
a lazy list, a unit delay is expressed by extending the 
list at its front with a new initial value, x_0:s. To 
delay an abstract stream, we can write 



mkStream (x_0,s) fst ((pr shd stl).snd) 
where prfgx=fx, gx 

A stream can represent the sequence of state valu¬ 
ations of a finite transition system. The shd function 
projects the visible part of the current state value. 
The state transition function is stl. 

A stateful function over a stream maps input el¬ 
ements to output elements but the map may depend 
upon the prior history of it use. The state can be rep¬ 
resented by an internal stream. Suppose Stream a is 
the type of inputs, Stream b the type of outputs, and 
s the type of the internal state. A stateful stream map 
can be programmed as 

mapStreamSt :: (a -> s -> b) -> 

s -> Stream a -> Stream b 
mapStreamSt fl f2 sO xs = 
mkStream (xs, sO) 

(\(x,s) -> fl (shd x) s) 

(\(x,s) -> (stl x, f2 (shd x) s)) 

3.2.4 A comonad of parallel threads 

Parallel evaluation may be supported by the context 
of a Haskell program but is not explicit in Haskell se¬ 
mantics. Parallel evaluation is an appropriate mecha¬ 
nism to represent abstractly with a comonad. It will 
allow a programmer to specify what segments of a 
program should be executed in parallel in the event 
that the program is run in an evaluation context that 
supports parallelism. 

Fine-grained parallel execution is commonly ex¬ 
pressed in terms of parallel threads. A thread exe¬ 
cutes concurrently with other threads without syn¬ 
chronizing its activity with them. Synchronization 
can be programmed explicitly by inserting the op¬ 
erator fence, to specify that the results of evaluat¬ 
ing an expression with a cluster of threads are to be 
combined before further computation is enabled. The 
value computed from the feneed expression is then re¬ 
turned to a single continuation thread in the context 
of the expression. 

Parallel threads can be expressed in terms of a 
comonad, 


Para = (hidden representation) 
co-eval = fence 

co-ext f = mapPar f. mkThread 
where / :: Para —>■ h 

The polymorphic operator mkThread :: Par a —>■ 
Par(Par a) starts a new thread. mapPar :: (a —>■ 
h ) —>■ Para —>■ Parh is the comonad map for Par. The 
effect of mapPar /allows an application of / to a suit¬ 
ably typed argument to be evaluated in the presence 
of parallel threads of computation. These operations 
are related by: 







3.2.' 


The OI comonad 


fence o mkThread = id 

Keep in mind that satisfaction of the above for¬ 
mula is not a trivial requirement. A multi-threaded 
evaluation model that cannot ensure the validity of 
this condition does not have the properties of a 
comonad for a functional language. This require¬ 
ment can be considered as a correctness condition 
for a multi-threaded implementation. Without it, 
the operational semantics of programs may be non- 
deterministic. 

Parallel evaluation of pairs If we designate the 
two-threaded, parallel evaluation of an expression e 
by (e||e), the semantics of fence can be expressed by 

fence = A(r||y). iUj 

To specify the parallel evaluation of two copies of an 
expression, we write mkThread e, which is equivalent 
to (e||e). _ 

A suitable domain for these semantics is a 
partially-ordered set in which the values, or com¬ 
putable elements are the prime elements of posets of 
approximating elements. An element p is prime with 
respect to a poset X if Vr, y £ X.p < xUy =>p<iV 
p < y. Then Par Q = ({X C Q \ X has a sup}, C) 
and co-eval X = sup X and f X = \_\{f Z \ Z C X}. 

For a program to invoke parallel evaluation to 
speed up its own computation on a platform that 
supports parallel threads, it must be possible to eval¬ 
uate the components of a pair in parallel. To spec¬ 
ify parallel evaluation of the components of a pair of 
expressions,(ei, e2) , we write mkThread (e i,e 2 ). If 
the immediate context of this parallel expression is 
fence, then an admissible strategy for its evaluation 
is to calculate (ei, _l_)||(_l_,e 2 ). The presence of _L as 
a component of a pair indicates that a thread need 
not invest any energy in evaluating that component. 
Evaluation of fence (mkThread (e i,e 2 )) is equivalent 
to ( ei , 1)||(1,e 2 ) = ( ei ,e 2 ). 

The Par comonad does not coexist comfortably 
with some other comonads, such as 10, in which the 
sequentialized behaviors of a series of interactions of 
a program with its environment can be observed. 
The type system can be used to identify safe cir¬ 
cumstances in which to invoke parallel evaluation. A 
function typed as n —>■ r 2 , where neither n nor r 2 
contains an occurrence of the type constructor 10, 
can be re-written to specify parallel evaluation of the 
function body without concern that multiple threads 
might interfere by invoking 10 actions. The parallel 
version acquires the type Par(ri) —>■ r 2 . 


We have argued previously that input-output oper¬ 
ations fit more naturally in a comonad than in a 
monad, because 10 effects are derived from the con¬ 
text of a program, not from the program itself. These 
effects cannot be expressed in the semantics of the 
programming language because they are manifested 
differently on various computational platforms. To 
avoid confusion with the 10 monad in Haskell, we 
shall use 01 as the name of the comonad. We can 
express 01 as a comonad with: 

01A = (hidden representation) 
co-eval = synchOI 
co-ext f = (mapOI f) . enableOI 
where / :: 01A ->■ B 

The operation synchOI commits all 10 activity whose 
effects may be observed by a program in execution or 
visible to its human operator, by flushing buffers and 
transmitting data. These operations are not directly 
controlled by an application program but they may be 
requested by a running application through its API. 

The combinator mapOI :: (A B) 01A —>■ 
01B has the operational effect of hiding all currently 
open files and buffers of the 10 system from the func¬ 
tion (program) it receives as an argument. Thus, that 
function could be a candidate for multi-threaded, par¬ 
allel evaluation. 

The polymorphic combinator enableOI :: OIA —>■ 
01(01 A) has the effect of copying pointers to cur¬ 
rently accessible 10 resources, in effect, duplicating 
the current 10 environment. The operational effect of 
co-ext /allows a function /, which accepts arguments 
that may depend upon the current 10 environment, 
to propagate the 10 environment as an implicit pa¬ 
rameter along with its result. 

An OI comonad in Haskell To experiment with 
comonadic input-output, several of the 10 primitives 
of Haskell have been repackaged in a module that 
imports the Haskell 10 module and exports a set of 
functions that produce the same behaviors but whose 
types are compatible with the 01 comonad. Some of 
these primitives are shown in the module declaration 
below. 

module 0I_comonad 
(01, 

coOpenFile, 
coGetChar, 
coPutChar, 
stdGetChar, 
stdPutChar, 
coClose) 
where 
import 10 
import IOExts 






import Comonad 

data 01 a = D a | forall b. StdOI b 

stdOI :: 01 a — this constant provides an 
stdOI = StdOI () — argument to which 01 oper- 

coOpenFile :: String -> IOMode -> 01 O -> Handle 
coOpenFile s m stdIO = 

unsafePerformlO (openFile s m) 

coGetChar :: 01 Handle -> Char 
coGetChar = 

\(D h) -> unsafePerformlO (hGetChar h) 

coPutChar :: Char -> 01 Handle -> O 
coPutChar = 

\c (D h) -> unsafePerformlO (hPutChar h c) 

stdGetChar :: 01 () -> Char 

stdGetChar stdOI = unsafePerformlO getChar 

stdPutChar :: 01 Char -> () 

stdPutChar = \(D c) -> unsafePerformlO (putChar c) 
coClose :: 01 Handle -> O 

coClose = \(D h) -> unsafePerformlO (hClose h) 

instance Comonad 01 where 
w =» f = D (f w) 
coeval (D a) = a 

A simple program using the 01 comonad is: 
module Bar 

import Comonad 
import 01 

echo :: String -> 01 a -> () 
echo s t = 

coeval (t =>> 

coOpenFile s ReadMode =>> 
coGetChar =>> 
stdPutChar) 

in which the second argument of echo is a token whose 
type permits the sequence of (=>>) operations to be 
invoked. When this module has been loaded, the ex¬ 
pression echo ‘ ‘alpha.txt’ ’ stdOI will then open 
a hie of the given name, if one is present, read a sin¬ 
gle character from the hie and print it to the standard 
output hie. 

The 01 package should not be taken to indicate 
how comonadic 10 operations should be implemented 
in a compiler, but only to show some operations 
and their types. The coercion unsafePerformlO ef¬ 
fectively performs a synchIO operation on each IO 
transaction. If the 01 module were implemented di¬ 
rectly from system primitives, rather than in terms 
of Haskell’s monadic IO primitives, it would not be 


necessary to design operators that synchronize the IO 
system to this degree. 

Another concession to expediency is dehnition of 
a constant, stdOI, with the polymorphic type 01 a. 
This was needed to provide an initial argument to the 
(=>>) operator. However, the presence of stdOI as 
a constant makes the encapsulation of IO operations 
by the 01 comonad unsafe, as it allows the applica¬ 
tion of an operation of type 01 a -> b to produce a 
side-effecting computation whose type, b, does not in¬ 
dicate that it may have such an effect. As mentioned 
earlier, a top-level program should provide a unique, 
initial application of (=>>) to enforce that IO effects 
are associated only with expressions typed in the 01 
comonad. 

3.2.6 The COM comonad 

This comonad is a bit more imaginative than are 
the others discussed in this paper, yet it seems con¬ 
sistent with the design goals of dynamically linked, 
component-based programming. A software compo¬ 
nent is an object characterized by a finite set of access 
methods whose types are given in a signature. The 
representation of a component is hidden. This allows 
any object with the same signature at its interface to 
be substituted for a given component. 

Dynamic linking permits a component to be im¬ 
ported from the evaluation context of a program in 
execution, giving the program access to the meth¬ 
ods of the components it imports. Dually, a program 
might export some objects, along with the signatures 
of their visible access methods, as new components. 
The mechanisms that support importation and ex¬ 
portation of components should be polymorphic; fur¬ 
thermore they should be related in ways that make 
the use of components uniform. If sufficiently well 
behaved, these mechanisms can constitute the data 
of an instance of a comonad. 

A comonad of components is described as: 

COMa = (hidden representation } 
co-eval= getlnterface 
co-ext /= (mapCOM f) . buildlnterface 
where / :: COMa ->■ b 


The method getlnterface is supported by every 
COM object and it always succeeds, yielding the 
typed interface of the object 5 . 








The function buildlnterface is polymorphic for ob¬ 
jects typed in the COM comonad, i.e. 

buildlnterface :: COM a ->■ COM (COM a) 

and may also be defined at some non -COM types. 
When buildlnterface is applied to an instance of an 
object, it constructs a COM interface, including pro¬ 
cedures for marshalling and unmarshalling param¬ 
eters of the types declared in the object’s method 
signature. Marshalling is only defined on types for 
which the respresentations of values are Unitary. Mar¬ 
shalling is a strict operation. 

The operations getlnterface and buildlnterface are 
related by: 

getlnterface o buildlnterface = id 

The signature of an object of type COM a contains 
only the method getlnterface. The result returned by 
this method is an interface whose type is a signature. 
The action of buildlnterface is uniform at all signa¬ 
ture types. At other than COM types, the action of 
buildlnterface may be specific to the type of its argu- 

A function of type COM a —>■ b is able to access 
a COM object passed to it as an argument but un¬ 
able to dynamically create COM objects out of the 
values it returns. Such a function is transformed by 
the co-ext combinator of this comonad into a fully 
COM- capable function that wraps its results in COM 
interfaces. 

4 Conclusions 

This paper suggests that Haskell could have codata 
types declared via its module system if it incorpo¬ 
rated a previously suggested extension to its type sys¬ 
tem: restricted rank 2 polymorphism. This extension 
presently exists in Hugs98. The codata type most fa¬ 
miliar to Haskell programmers is probably the type 
(constructor) of streams, simulated in Haskell pro¬ 
grams by unbounded lists, lazily evaluated. With an 
abstract codata type, however, its representation can 
be hidden. Also, the evaluated segments of a codata 
object are not cached by defaut. 

Although streams are the only types of codata 
given as examples in this paper, other examples are 
not difficult to imagine. In particular, abstract data 
types, as they are usually construed in a functional 
programming language, fit the definition of codata. 
Representation hiding is an essential aspect of ab¬ 
stract data types and should be supported in Haskell. 
Restricted rank 2 polymorphism would suffice. 

A second suggestion is to provide comonads in 
Haskell by including a Comonad class in the standard 
prelude, and providing syntax for a top-level program 
to apply the co-extension of a function typed in a 


comonad to an implicit argument. This extension 
would support comonads whose operational seman¬ 
tics are defined in an execution context. 

We have argued that comonads provide a natu¬ 
ral abstraction of the effects that arise in the context 
of a program, such as input/output, component in¬ 
terfaces and parallel evaluation. There are other ex¬ 
amples of comonads which have not been discussed 
in this paper because they are less compelling as po¬ 
tential extensions of Haskell. These examples include 
concurrent communicating processes, exceptions and 
explicit continuations. 
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